Add missing decorators: @versioning_class(), @content_negotiation_class(), @metadata_class()
#9719
Conversation
Yes, I think that if you add one, it makes sense to add all 3 that you found were missing 👍🏻 |
qqii
changed the title
@versioning_class()@versioning_class(), @content_negotiation_class(), @metadata_class()
|
Sure @browniebroke, I've amended this PR to add all of them. Do the tests for |
| @@ -186,6 +186,9 @@ The available decorators are: | |||
| * `@authentication_classes(...)` | |||
| * `@throttle_classes(...)` | |||
| * `@permission_classes(...)` | |||
| * `@content_negotiation_class(...)` | |||
| * `@metadata_class(...)` | |||
| * `@versioning_class(...)` | |||
|
|
|||
| Each of these decorators takes a single argument which must be a list or tuple of classes. | |||
There was a problem hiding this comment.
That statement needs to be updated, the ones we're adding are accepting a single class, not a list or tuple of classes.
There was a problem hiding this comment.
Good point. My guess is the original wording is meant to clarify that they should be used like
@api_view(["GET"])
@renderer_classes([RenderA, RenderB])
def view(request):
passrather than
@api_view(["GET"])
@render_classes(RenderA, RenderB)
def view(request):
passHow about something like:
Each of these decorators is equivalent to setting their respective api policy attributes.
Decorators that end withclassestake a single argument which must be a list or tuple of classes.
There was a problem hiding this comment.
Good start, I would go one step further and explicitly outline what each form expect. Something along the lines of:
Each of these decorators is equivalent to setting their respective api policy attributes.
All decorators take a single argument. The ones that end with_classexpect a single class while the ones ending in_classesexpect a list or tuple of classes.
This adds the three missing decorators, fixing #9716.
@content_negotiation_class()@metadata_class()@versioning_class()